Information management of mobile device data

ABSTRACT

A method and system for providing information management of mobile device data provides a user interface to permit a user of an information management system to define information management policies for the mobile device, receives definitions of the information management policies from the provided interface, and sends data from the mobile device to the information management system in accordance with the information management policies. In some examples, the system sends information identifying the user and the mobile device to the information management system, and/or sends the information management policies defined from the interface to the information management system.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority to and the benefit of U.S.Provisional Application No. 61/618,506, filed Mar. 30, 2012, which ishereby incorporated herein by reference in its entirety.

BACKGROUND

Increasingly, people generate data and metadata across multiplecomputing devices and multiple hosted services. For example, during thecourse of a single day, a person may use a laptop computer, desktopcomputer, tablet computer, and smartphone in order to view and editfiles, e-mails, or other data objects. As another example, a person mayuse hosted solutions such as Facebook, Gmail, Google Docs, andsalesforce.com to communicate with others and conduct work. A person maynot be able to access the files and information they need readily from asingle interface, since the files are scattered across multiplecomputing devices and hosted sites. Moreover, conventional informationmanagement systems are often focused on organizing, protecting, andrecovering the data from fixed computing devices, such as servers ordesktop computers. As a result, a person's hosted data and mobile datamay be scattered outside of the purview of conventional informationmanagement systems and that data will therefore not be backed up orotherwise actively managed. Thus, in the event that a mobile device islost or broken or a hosted service has a service disruption, there is arisk that a person's critical data may be lost, without any way torecover it.

The need exists for systems and methods that overcome the aboveproblems, as well as systems and methods that provide additionalbenefits. Overall, the examples herein of some prior or related systemsand methods and their associated limitations are intended to beillustrative and not exclusive. Other limitations of existing or priorsystems and methods will become apparent to those of skill in the artupon reading the following Detailed Description.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an example of a suitableinformation management environment in which aspects of the inventivesystems and methods may operate.

FIG. 2 illustrates examples of production and non-production data thatmay be processed by the information management environment of FIG. 1.

FIG. 3 is a block diagram illustrating one example of a hierarchicalarrangement of resources for the information management system of FIG.1, including information management cells.

FIG. 4 is a block diagram illustrating an example of resources formingan information management cell.

FIG. 5 is a flow chart that illustrates a process for collecting andmanaging a user's hosted data.

FIG. 6 illustrates an example of a graphical user interface forreceiving authentication information and information management policiesfor hosted accounts.

FIG. 7A is a flow chart that illustrates a process for sending mobiledevice data to an information management system that may be performed ata mobile device.

FIG. 7B is a flow chart that illustrates a process for collecting andmanaging mobile device data that may be performed at a distributionmodule.

FIG. 7C illustrates one example of a graphical user interface that maybe provided in order to receive authentication information andmanagement policies for mobile data.

FIG. 8A is a flow chart that illustrates a process for managing a user'sdata that may be performed at a distribution module.

FIG. 8B is a flow chart that illustrates a process for managing a user'sdata that may be performed at a computing device.

FIG. 9A illustrates an example of a graphical user interface forreceiving distribution policies for a user's data.

FIG. 9B illustrates an example of a graphical user interface fordefining a distribution policy.

FIG. 10 shows an example of an object log index.

FIG. 11 shows an example of a distribution index.

FIG. 12 is a flow chart that illustrates a process for providing a userwith unified access to all of her hosted data and data from othercomputing devices.

FIG. 13 illustrates an example of a graphical user interface forproviding a user with unified access to all of her hosted data and datafrom other computing devices.

FIG. 14 is a flow chart that illustrates a process for providing a userwith access to her data that may be performed at a distribution module.

FIGS. 15A and 15B show illustrative examples of a native interface to anapplication and a “live browse” interface.

DETAILED DESCRIPTION

The headings provided herein are for convenience only and do notnecessarily affect the scope or meaning of the disclosure.

Overview

A software, firmware, and/or hardware system for comprehensiveinformation management is disclosed. The system helps collect, manageand distribute, in a unified fashion, data and metadata from numeroussources, including data and metadata originating from hosted servicesand mobile devices. The system can help a user obtain a unified view ofher data across numerous devices and also keep data synchronized acrossnumerous computing devices associated with the user. The system permitsusers to define simple or complex data distribution policies to helpdrive data distribution and synchronization across the user's devices.The system allows a user on a mobile device to perform “live browsing”of the files on another computing device that is associated with theuser. The system also permits a user of a mobile device or otherlimited-feature device to execute full-featured applications installedon a remote computing device (e.g., a desktop or laptop device) and tointeract with the full-featured application via the input-outputhardware of the limited-feature device.

The system offers numerous benefits. First, from a single interface,users can browse and search for files from practically any of theircomputing devices or hosted services and access those files. Second, thesystem provides a closed corporate collaboration environment where dataobjects are exchanged and synchronized across multiple devices, butusing the resources of a private information management system, not anuntrusted or untried third-party service. As a result, copies of anorganization's data objects are not unnecessarily exposed to othersbecause the copies do not need to be stored or controlled by thirdparties. Third, the system permits an organization to better comply withdata retention regulations and other regulations by capturing andmanaging practically all of a user's data, not just the user's data thatoriginates from fixed computing devices. Fourth, the system can permitan organization to better respond to unexpected data losses, such as theloss of a mobile device or a service outage by a hosted service, becausethe system is actively managing copies of mobile data and hosted data.Other benefits are of course possible.

Various examples of the invention will now be described. The followingdescription provides specific details for a thorough understanding andenabling description of these examples. One skilled in the relevant artwill understand, however, that the invention may be practiced withoutmany of these details. Likewise, one skilled in the relevant art willalso understand that the invention may include many other obviousfeatures not described in detail herein. Additionally, some well-knownstructures or functions may not be shown or described in detail below,so as to avoid unnecessarily obscuring the relevant description.

The terminology used below is to be interpreted in its broadestreasonable manner, even though it is being used in conjunction with adetailed description of certain specific examples of the invention.Indeed, certain terms may even be emphasized below; however, anyterminology intended to be interpreted in any restricted manner will beovertly and specifically defined as such in this Detailed Descriptionsection.

Information Management Environment

Aspects of the technologies described herein may be practiced in aninformation management environment 100, which will now be describedwhile referencing FIG. 1. As shown in FIG. 1, the environment 100includes multiple computing devices that execute numerous softwareapplications to facilitate the operations of an organization (ormultiple affiliated organizations), such as a household, corporation orother business entity, a non-profit organization, an educationalinstitution, or a governmental agency. The computing devices may includeone or more: servers 105 (such as mail servers, file servers, databaseservers, print servers, and web servers), personal computers 110,workstations 115, or other types of fixed computing systems such asmainframe computers and minicomputers (not shown). The servers 105 mayinclude network-attached storage (NAS) filers.

The environment 100 may include virtualized computing resources, such asa virtual machine 120 provided to the organization by a third-partycloud service vendor or a virtual machine 125 running on a virtualmachine host 130 operated by the organization. For example, theorganization may use one virtual machine 125A as a database server andanother virtual machine 125B as a mail server. The environment 100 mayalso include mobile or portable computing devices, such as laptops 135,tablet computers 140, personal data assistants 145, mobile phones 152(such as smartphones), and other mobile or portable computing devicessuch as embedded computers, set top boxes, vehicle-mounted devices,wearable computers, etc.

Of course, other types of computing devices may form part of theenvironment 100. As part of their function, each of these computingdevices creates, accesses, modifies, writes, and otherwise usesproduction copies of data and metadata that are typically stored in apersistent storage medium having fast I/O times. For example, eachcomputing device may regularly access and modify data files and metadatastored on semiconductor memory, a local disk drive or a network-attachedstorage device. Each of these computing devices may access data andmetadata via a file system supported by an operating system of thecomputing device.

The environment 100 may also include hosted services 122 that providevarious online services to the organization or its constituent members(e.g., the organization's departments, employees, independentcontractors, etc.) such as social networking services (e.g., Facebook,Twitter, Pinterest), hosted email services (e.g., Gmail, Yahoo Mail,Hotmail), or hosted productivity applications or other hostedapplications (e.g., Microsoft Office 365, Google Docs, Salesforce.com).Hosted services may include software-as-a-service (SaaS),platform-as-a-service (PaaS), application service providers (ASPS),cloud services, and all manner of delivering computing or functionalityvia a network. As it provides services to users, each hosted service maygenerate additional “hosted data and metadata” that is associated witheach user. For example, Facebook may generate and store photos, wallposts, notes, videos, and other content that are associated with aparticular Facebook user's account.

The organization directly or indirectly employs an informationmanagement system 150 to protect and manage the data and metadata usedby the various computing devices in the environment 100 and the data andmetadata that is maintained by hosted services on behalf of usersassociated with the organization. One example of an informationmanagement system is the CommVault Simpana system, available fromCommVault Systems, Inc. of Oceanport, N.J. The information managementsystem creates and manages non-production copies of the data andmetadata to meet information management goals, such as: permitting theorganization to restore data, metadata or both data and metadata if anoriginal copy of the data/metadata is lost (e.g., by deletion,corruption, or disaster, or because of a service interruption by ahosted service); allowing data to be recovered from a previous time;complying with regulatory data retention and electronic discovery(“e-discovery”) requirements; reducing the amount of data storage mediaused; facilitating data organization and search; improving user accessto data files across multiple computing devices and/or hosted services;and implementing information lifecycle management (“ILM”) or other dataretention policies for the organization. The information managementsystem 150 may create the additional non-production copies of the dataand metadata on any suitable non-production storage medium such asmagnetic disks 155, magnetic tapes 160, other storage media 165 such assolid-state storage devices or optical disks, or on cloud data storagesites 170 (e.g. those operated by third-party vendors). Further detailson the information management system may be found in the assignee's U.S.patent application Ser. No. 12/751,850, filed Mar. 31, 2010 entitledDATA OBJECT STORE AND SERVER FOR A CLOUD STORAGE ENVIRONMENT, INCLUDINGDATA DEDUPLICATION AND DATA MANAGEMENT ACROSS MULTIPLE CLOUD STORAGESITES, now U.S. Patent Publication Number 2010-0332456 (attorney docket606928075U502), which is hereby incorporated by reference herein in itsentirety.

FIG. 2 helps illustrates some differences between “production copies” ofdata and metadata and “non-production copies” of data and metadata inthe data management environment 100. As shown, each computing device 205in the environment 100 has at least one operating system 210 installedand one or more applications 215A-D, such as mail server applications,file server applications, mail client applications, databaseapplications, word processing applications, spreadsheet applications,presentation applications, browser applications, mobile applications,entertainment applications, and so on. Each application can access andmodify various production copies of files stored in a production datastorage medium 218, which may be a network attached storage filer orform part of a Hadoop distributed file system, Open VMS file system, orother type of distributed file system, simply by making conventionalfile system calls via the operating system 210, without needing theinformation management system 150 to intervene on behalf of theoperating system or application. The production copies of files mayinclude structured data (e.g., database files), unstructured data (e.g.,documents), and/or semi-structured data, and thus may include one ormore documents 220A-B, spreadsheets 225, presentation documents 230,video files 232, image files 234, email mailboxes 235, html/xml or othertypes of markup language files 222, and/or databases 240. The operatingsystem 210 may also access and modify production copies of files andother data, such as files in a system volume and/or boot volume. Thehosted data and metadata used by a hosted service are also “productioncopies” of data and metadata since the hosted service accesses andmodifies the user's data and metadata as part of its services.Production copies of data may include not only files, but also subsetsof files, each of which a related application 215 or the operatingsystem 210 treats as an independent functional unit, but which is notseparately addressed in the associated file system. For example, asingle email mailbox 235 may include multiple email messages 245A-C,email headers, and attachments. As another example, a single database240 may include multiple tables 255A-C. As used herein, a “data object”refers to both (1) any file that is currently or previously addressableby a file system and (2) a functional subset of such a file that has aparticular function for a related application 215A-D or the operatingsystem 210. Each data object may be further decomposed into one or moredata blocks each of which is a collection of data bits within the dataobject that may not have any particular function for a relatedapplication or the operating system. In addition to data objects, theoperating system 210 and applications 215A-D may also access and modifyproduction copies of metadata, such as boot sectors, partition layouts,file or data object metadata (e.g., file name, file size,creation/modification/access timestamps, file location within a filefolder directory structure, user permissions, owners, groups, accesscontrol lists (“ACLS”)), and system metadata (e.g., registryinformation). In addition to metadata generated by or related to filesystems and operating systems, some applications maintain indices ofproduction metadata for data objects, e.g., metadata associated withindividual email messages. Thus, as shown in FIG. 2, each data objectmay be associated with a production copy of object metadata(“Meta1-11”), which may be file system metadata and/orapplication-specific metadata.

The information management system 150 accesses or receives copies of thevarious production copies of data objects and metadata, and via aninformation management operation (such as a backup operation, archiveoperation, or snapshot operation), creates non-production copies ofthese data objects and metadata, often stored in one or morenon-production storage mediums 265 different than the production storagemedium 218 where the production copies of the data objects and metadatareside. A non-production copy of a data object represents the productiondata object and its associated metadata at a particular point in time(non-production objects 260A-C). Since a production copy of a dataobject or metadata changes over time as it is modified by an application215, hosted service 122, or the operating system 210, the informationmanagement system 150 may create and manage multiple non-productioncopies of a particular data object or metadata, each representing thestate of the production data object or metadata at a particular point intime. Moreover, since a production copy of a data object may eventuallybe deleted from the production data storage medium and the file systemfrom which it originated, the information management system may continueto manage point-in-time representations of that data object, even thougha production copy of the data object itself no longer exists.

For virtualized computing devices, such as virtual machines, theoperating system 210 and applications 215A-D may be running on top ofvirtualization software, and the production data storage medium 218 maybe a virtual disk created on a physical medium such as a physical disk.The information management system may create non-production copies ofthe discrete data objects stored in a virtual disk file (e.g.,documents, email mailboxes, and spreadsheets) and/or non-productioncopies of the entire virtual disk file itself (e.g., a non-productioncopy of an entire .vmdk file).

Each non-production object 260A-C may contain copies of or otherwiserepresent more than one production data object. For example,non-production object 260A represents three separate production dataobjects 255C, 230 and 245C (represented as 245C′, 230′ and 245′,respectively). Moreover, as indicated by the prime mark (′), anon-production object may store a representation of a production dataobject or metadata differently than the original format of the dataobject or metadata, e.g., in a compressed, encrypted, deduplicated, orotherwise optimized format. Although FIG. 2 shows that a singleproduction data object (e.g., 255C), and its associated data objectmetadata (e.g., Meta11) are represented by the contents of only a singlenon-production object (e.g., 260A), the entire contents of a singleproduction data object and/or its metadata at a particular point in timemay instead span across numerous non-production objects. Also a singlenon-production object 260 may contain copies of or otherwise representproduction data objects that originated from different computingdevices.

Non-production copies include backup copies, archive copies, andsnapshot copies. Backup copies are generally used for shorter-term dataprotection and restoration purposes and may be in a native applicationformat or in a non-native format (e.g., compressed, encrypted,deduplicated, and/or otherwise modified from the original applicationformat). Archive copies are generally used for long-term data storagepurposes and may be compressed, encrypted, deduplicated and/or otherwisemodified from the original application format. In some examples, when anarchive copy of a data object is made, a logical reference or stub maybe used to replace the production copy of the data object in theproduction storage medium 218. In such examples, the stub may point toor otherwise reference the archive copy of the data object stored in thenon-production storage medium so that the information management systemcan retrieve the archive copy if needed. The stub may also include somemetadata associated with the data object, so that a file system and/orapplication can provide some information about the data object and/or alimited-functionality version (e.g., a preview) of the data object. Asnapshot copy represents a data object at a particular point in time. Asnapshot copy can be made quickly and without significantly impactingproduction computing resources because large amounts of data need not becopied or moved. A snapshot copy may include a set of pointers derivedfrom the file system or an application, where each pointer points to arespective stored data block, so collectively, the set of pointersreflect the storage location and state of the data object at aparticular point in time when the snapshot copy was created. In“copy-on-write”, if a block of data is to be deleted or changed, thesnapshot process writes the block to a particular data storage location,and the pointer for that block is now directed to that particularlocation. The set of pointers and/or the set of blocks pointed to by asnapshot may be stored within the production data storage medium 218.

Non-production copies of a data object or metadata may be distinguishedfrom a production copy of a data object or metadata in several ways.First, a non-production copy of a data object is created to meet thedifferent information management goals described above and is notdirectly used or modified by applications 215A-D, hosted services 122,or the operating system 210. Second, a non-production copy of a dataobject is stored as one or more non-production objects 260 that may havea format different from the native application format of the productioncopy of the data object, and thus often cannot be directly used by thenative application or a hosted service 122 without first being modified.Third, non-production objects are often stored on a non-productionstorage medium 265 that is inaccessible to the applications 215A-Drunning on computing devices and hosted services 122. Also, somenon-production copies may be “offlline copies,” in that they are notreadily available (e.g. not mounted tape or disk.) Offline copiesinclude copies of data that the information management system can accesswithout any human intervention (e.g. tapes within an automated tapelibrary, but not yet mounted in a drive), and copies that theinformation management system 150 can access only with at least somehuman intervention (e.g. tapes located at an offsite storage site).

The information management system 150 also generates informationmanagement data 275, such as indexing information, that permit theinformation management system to perform its various informationmanagement tasks. As shown in FIG. 2, a computing device 205 may includeone or more data management agents 280 that provide client-sidefunctions for the information management system.

Information Management System

FIG. 3 shows a hierarchical arrangement of resources that may form aninformation management system 150. As shown, the information managementsystem 150 includes multiple information management cells 350 arrangedin a hierarchy, with some information management cells (e.g., 350D-E)subordinate to other information management cells (e.g., 350B). A globalstorage manager 305, which may form part of a global information cell350 x, manages the overall hierarchy of information management cells byreceiving reports from the various subordinate information managementcells related to the operation of the cells, determining globalinformation management policies in light of received reports, andpushing information management policies towards subordinate cells forimplementation. The global storage manager may also maintain anddisseminate, to the various cells, system-wide information managementdata. A superior information management cell (e.g., 350B), may performsimilar tasks for its subordinate cells (e.g., 350D-E) and/or otherwiseact as an intermediary between the subordinate cells and the globalstorage manager 305.

Information Management Cell

FIG. 4 shows an arrangement of resources that may form an informationmanagement cell 350. As shown, the information management cell includesa storage manager 402, one or more media agents 410A-M, one or morenon-production storage mediums 155-870, one or more computing devices205A-N, and one or more production data storage mediums 218A-N. Outsideof the information management cell are hosted services 122, which mayinteract with media agents 410 and its components, as described furtherherein. In some examples, all or a portion of an information managementcell may be implemented as an object store, as described in assignee'sU.S. patent application Ser. No. 12/751,850 (introduced more fully andincorporated by reference above).

The storage manager 402 may be a software module or other applicationthat coordinates and controls information management operationsperformed by one or more information management cells 350 to protect andcontrol copies of non-production data objects and metadata. As shown bythe dashed lines 416 and 422, the storage manager may communicate withsome or all elements of the information management cell 350, such as themedia agents 410 and computing devices 205, to initiate and managebackup operations, snapshot operations, archive operations, datareplication operations, data migrations, data distributions, datarecovery, and other information management operations. The storagemanager may control additional information management operationsincluding ILM, deduplication, content indexing, data classification,data mining or searching, e-discovery management, collaborativesearching, encryption, and compression. Alternatively or additionally, astorage manager may control the creation and management of disasterrecovery copies, which are often created as secondary, high-availabilitydisk copies, using auxiliary copy or replication technologies.

The storage manager 402 may include a jobs agent 455, a management agent450, a network agent 445, and an interface agent 460, all of which maybe implemented as interconnected software modules or applicationprograms. The jobs agent 455 monitors the status of informationmanagement operations previously performed, currently being performed,or scheduled to be performed by the information management cell 350. Themanagement agent 450 provides an interface that allows variousmanagement agents 450 in multiple information management cells 350 (orin a global storage manager 305) to communicate with one another. Thisallows each information management cell 350 to exchange statusinformation, routing information, capacity and utilization information,and information management operation instructions or policies with othercells. In general, the network agent 445 provides the storage manager402 with the ability to communicate with other components within theinformation management cell and the larger information managementsystem, e.g., via proprietary or non-proprietary network protocols andapplication programming interfaces (“APIs”) (including HTTP, HTTPS, FTP,REST, virtualization software APIs, cloud service provider APIs, hostedservice provider APIs). The interface agent 460 includes informationprocessing and display software, such as a graphical user interface(“GUI”), an API, or other interactive interface through which users andsystem processes can retrieve information about the status ofinformation management operations or issue instructions to theinformation management cell and its constituent components. The storagemanager 402 may also track information that permits it to select,designate, or otherwise identify content indices, deduplicationdatabases, or similar databases within its information management cell(or another cell) to be searched in response to certain queries.

The storage manager 402 may also maintain information management data,such as a database 465 of management data and policies. The database 465may include a management index that stores logical associations betweencomponents of the system, user preferences, user profiles (that amongother things, map particular information management users to computingdevices or hosted services), management tasks, or other useful data. Thedatabase 465 may also include various “information management policies,”which are generally data structures or other information sources thateach includes a set of criteria and rules associated with performing aninformation management operation. The criteria may be used to determinewhich rules apply to a particular data object, system component, orinformation management operation, an may include:

-   -   frequency with which a production or non-production copy of a        data object or metadata has been or is predicted to be used,        accessed, or modified;    -   access control lists or other security information;    -   the sensitivity (e.g., confidentiality) of a data object as        determined by its content and/or metadata;    -   time-related factors;    -   deduplication information;    -   the computing device, hosted service, computing process, or user        that created, modified, or accessed a production copy of a data        object; and    -   an estimated or historic usage or cost associated with different        components.        The rules may specify, among other things:    -   a schedule for performing information management operations,    -   a location (or a class or quality of storage media) for storing        a non-production copy,    -   preferences regarding the encryption, compression, or        deduplication of a non-production copy,    -   resource allocation between different computing devices or other        system components (e.g., bandwidth, storage capacity),    -   whether and how to synchronize or otherwise distribute files or        other data objects across multiple computing devices or hosted        services,    -   network pathways and components to utilize (e.g., to transfer        data) during an information management operation, and    -   retention policies (e.g., the length of time a non-production        copy should be retained in a particular class of storage media).

As noted above, each computing device 205 may include one or more datamanagement agents 280. Each data management agent is a software moduleor component that helps govern communications with other systemcomponents. For example, the data management agent receives commandsfrom the storage manager 402 and sends to and receives from media agents410 copies of data objects, metadata, and other payload (as indicated bythe heavy arrows). Each data management agent accesses data and/ormetadata stored in a production data storage medium 218 and arranges orpacks the data and metadata in a certain format (e.g., backup or archiveformat) before it is transferred to another component. Each datamanagement agent can also restore a production copy of a data object ormetadata in a production data storage medium 218 from a non-productioncopy. A data management agent may perform some functions provided by amedia agent, which are described further herein, such as compression,encryption, or deduplication. Each data management agent may bespecialized for a particular application (e.g. a specified datamanagement agent customized to handle data generated or used by Exchangeby Microsoft Corp.). Alternatively or additionally, a more generic datamanagement agent may handle data generated or used by two or moreapplications.

Each computing device 205 may also include a data distribution and livebrowsing client module 405 (herein “distribution client module”). Thedistribution client module 405 is responsible for, inter alia,associating mobile devices and/or hosted service accounts with users ofthe information management system, setting information managementpolicies for mobile and other computing devices, pushing data objects toa distribution module for distribution to other computing devices,providing unified access to a user's data via an interface, andproviding live browsing features. The various functions of thedistribution client module are described in greater detail herein.

A media agent 410, which may be implemented as a software module,conveys data, as directed by the storage manager 402, between acomputing device 205 (or hosted service 122) and one or morenon-production storage mediums 155-870. Each media agent 410 may controlone or more intermediary storage devices 418, such as a cloud server ora tape or magnetic disk library management system, to read, write, orotherwise manipulate data stored in a non-production storage medium155-870. Each media agent 410 may be considered to be “associated with”a storage device and its related non-production storage media if thatmedia agent is capable of routing data to and storing data in thestorage media managed by the particular storage device. A media agentmay communicate with computing devices 205, hosted services 122, storagedevices 418A-D, and the storage manager 402 via any suitablecommunications path, including SCSI, a Storage Area Network (“SAN”), aFibre Channel communications link, or a wired, wireless, or partiallywired/wireless computer or telecommunications network, including theInternet.

To perform its functions, the media agent 410 may include a media filesystem module 425, a data classification module 435, a content indexingmodule 420, a deduplication module 430, an encryption module 475, acompression module 485, a network module 415, a distribution module 490,and a media agent database 440. The media file system module 425 isresponsible for reading, writing, archiving, copying, migrating,restoring, accessing, moving, sparsifying, deleting, sanitizing,destroying, or otherwise performing file system operations on variousnon-production storage devices of disparate types. The media file systemmodule may also instruct the storage device to use a robotic arm orother retrieval means to load or eject certain storage media such as atape.

The network module 415 permits the media agent to communicate with othercomponents within the system and hosted services 122 via one or moreproprietary and/or non-proprietary network protocols or APIs (includingcloud service provider APIs, virtual machine management APIs, and hostedservice provider APIs). The deduplication module 430 performsdeduplication of data objects and/or data blocks to reduce dataredundancy in the cell. The deduplication module may generate and storedata structures to manage deduplicated data objects, such asdeduplication tables, in the media agent database 440. The encryptionmodule 475 performs encryption of data objects, data blocks, ornon-production objects to ensure data security in the cell. Thecompression module 485 performs compression of data objects, datablocks, or non-production objects to reduce the data capacity needed inthe cell.

The content indexing module 420 analyzes the contents of productioncopies or non-production copies of data objects and/or their associatedmetadata and catalogues the results of this analysis, along with thestorage locations of (or references to) the production or non-productioncopies, in a content index stored within a media agent database 440. Theresults may also be stored elsewhere in the system, e.g., in the storagemanager 402, along with a non-production copy of the data objects,and/or an index cache. Such index data provides the media agent 410 oranother device with an efficient mechanism for locating productioncopies and/or non-production copies of data objects that matchparticular criteria. The index data or other analyses of data objects ormetadata may also be used by the data classification module 435 toassociate data objects with classification identifiers (such asclassification tags) in the media agent database 440 (or other indices)to facilitate information management policies and searches of storeddata objects.

The distribution module 490 may be a set of instructions thatcoordinates the distribution of data objects and indices of dataobjects. The distribution may occur from one computing device 205 toanother computing device 205 and/or from hosted services 122 tocomputing devices 205. As a first example, the distribution module maycollect and manage data and metadata from hosted services 122 or mobiledevices 205. As another example, the distribution module may synchronizedata files or other data objects that are modified on one computingdevice so that the same modified files or objects are available onanother computing device. As yet another example, the distributionmodule may distribute indices of data objects that originated frommultiple computing devices and/or hosted services, so a user can accessall of their data objects through a unified user interface or a nativeapplication on their computing device. The distribution module may alsoinitiate “live browse” sessions to permit communications betweendifferent computing devices so that the devices can interchange data andmetadata or so the devices can provide computing resources, such asapplications, to each other. The functions performed by the distributionmodule are described in greater detail herein.

Managing Hosted Data

To provide comprehensive management of all of an organization's data,the information management system 150 (or IMS) may collect and managehosted data associated with individual users of the IMS, such asindividual employees or members of the organization that operate orutilize the IMS. FIG. 5 shows a process 500 for collecting and managinghosted data in an information management system. The process 500 may beperformed by the distribution module 490 or another system component.The process 500 begins at block 505, where the distribution modulereceives authentication information and information management policiesfor the hosted services accounts (or simply “hosted accounts”)associated with a user of the information management system. Forexample, the distribution module may receive an indication that thedistribution module should periodically collect copies of the data andmetadata associated with the user's hosted accounts on social networkingsites (e.g., Facebook, Foursquare, Twitter), hosted email services(e.g., Gmail, Yahoo mail, Hotmail), hosted applications (e.g., Office365, Google Documents, and Salesforce), or other hosted services.

FIG. 6 illustrates one example of a graphical user interface 600 thatthe distribution module may provide in order to receive authenticationinformation and information management policies for hosted accounts. Asshown, the interface 600 may include IMS username and password fields602 and 604 so that the user can provide authentication information orother credentials that identify the person as a registered user of theinformation management system 150 (e.g., as IMS user “jane65”).Alternatively, the IMS user may be identified using credentials obtainedfrom an operating system or directory or security service, such as anActive Directory service. Although not shown, the interface 600 may alsoinclude a field to permit the IMS user to provide an identifierassociated with the particular IMS they are associated with.

The interface 600 also includes several selection boxes 605 or similarelements to permit the user to identify the hosted accounts the userhas. For illustrative purposes, the interface 600 shows only the hostedservices Facebook, Flickr, LinkedIn, Twitter, Gmail, Dropbox, andBox.net. However, as indicated by the services selection field 630, theinformation management system may also support numerous other hostedservices, including practically any hosted service that generatesproduction data and metadata for a user and provides APIs or otherinterfaces that permit the distribution module to access the user's dataand metadata. For each selected service, the interface 600 providesusername and password fields, 610 and 615, where the user can enterhosted account authentication information or credentials to permit theIMS to access the user's data and metadata hosted on the service.

For each selected service, the interface also includes a policyselection dropdown menu 620 or similar selection means so that the usercan associate the selected service with a particular informationmanagement policy for collecting and managing the service's hosted dataand metadata. A policy may include any of the criteria and rulesdescribed above in connection with the discussion of informationmanagement policies generally. The selected policy may specify howfrequently the distribution module should collect hosted data from theservice, the type or other characteristics of hosted data that thedistribution module should collect (e.g., all data versus photos versusdocuments, etc.), and/or the types of information management operationsthat the IMS should perform on collected hosted data (e.g.,deduplication, content indexing, data classification, archiving, back upoperations, etc.). The selected policy may also specify where or hownon-production copies of the hosted data should be stored. The interfacecan include options for all of these criteria and rules, as well asother criteria and rules.

As shown with element 620 a, to simplify the user experience, theinterface 600 may provide a suggested default or mandatory policy (e.g.,“FB default” policy) for each service (e.g., all data content iscollected twice a day). For each selected service, the interface 600 mayalso include an alias field 635 where a user can provide a descriptivealias for the hosted account, to permit the user and the IMS to readilyidentify the hosted account as a data source for the user.

The interface 600 may be presented to a user via a web browser (e.g., asa web portal), or may be presented to a user via a mobile application orother application installed on the user's computing device, such as amobile device. For example, the interface 600 may be provided by thesame application used to produce the interface 770, which is describedfurther herein. In examples where the interface 600 is presented via amobile application, some or all of the entry fields may beauto-populated by the application. For example, the applicationproducing interface 600 may detect other applications installed on themobile device that are associated with hosted services or local datarelated to these other applications. For example, the application usedto produce interface 600 may detect that a user's mobile device has aFacebook application installed and may therefore automatically select“Facebook.”

Although not shown in FIG. 6, it should be noted that the informationmanagement system 150 permits administrators of the informationmanagement system 150 to define or modify information managementpolicies for the hosted data of other users, including policies thatprohibit the collection and management of certain hosted data. Forexample, an IMS administrator may create a system-wide policy thatspecifies that photos or videos that originate from any employee'sFacebook hosted account cannot be collected. The IMS may disregard oroverride any information management policies set by an individual userto the extent that those individual rules are contrary to anadministrator-defined policy.

Returning to the process 500 of FIG. 5, at block 510, the distributionmodule 490 associates the hosted account information received at block505 with the IMS user. For example, in an IMS user profile datastructure, the distribution module may associate the IMS user identifiedby fields 602 and 604 with the hosted services, aliases, authenticationinformation, and policies received at block 505.

At block 515, the distribution module 490 sets or adjusts informationmanagement policies to govern the collection and management of thehosted data associated with the user. For example, in accordance withthe user's policy preferences that were received at block 505 (and anyadministrator-defined policies), for each hosted service selected, thedistribution module may set a policy specifying which of the user'shosted data should be collected from the service and the schedule forcollecting the hosted data. Continuing the previous example, thedistribution module may set a policy to collect all of the user jane65'sdata and metadata from her “Facebook Jane” account twice a day.

At block 520, the distribution module 490 collects hosted data andmetadata in accordance with the applicable information managementpolicies that were set at block 515. To do so, the distribution modulemay utilize general or service-specific APIs to request any new data ormetadata associated with a user's hosted account on the prescribedschedule. As part of its request, the distribution module may providethe authentication or credential information (e.g., username/password orother credentials) that it received at block 505 in order to gain accessto the user's hosted data and metadata.

The process 500 ends at block 525, where the distribution module 490manages collected hosted data in accordance with applicable informationmanagement policies. For example, the distribution module may performdeduplication, content indexing, data classification, and/or archiving;create additional non-production copies (e.g., backup copies or archivecopies); restore copies of the data and metadata to a productionlocation; or perform information lifecycle management of the hosted datain accordance with the applicable information management policies set atblock 515.

In some examples, the distribution module may restore or expose hosteddata at a new location that is different from its original hostedlocation so that an organization can interact with the data in adifferent fashion. For example, the distribution module may restore IMAPdata that was generated by a first hosted email service (e.g., Gmail) sothat it is accessible via a second hosted email service (e.g., Hotmail)or a local email client (e.g., Outlook). As another example, thedistribution module may restore hosted data to an organization's networkattached storage filer. In such an example, data that was previouslyaccessible only via a service-specific API of a hosted service would nowbe accessible to the organization via Network File System or CommonInternet File System protocols.

Managing Mobile Device Data

To provide comprehensive management of all of an organization's data,the information management system 150 may also collect and manage dataand metadata generated by the mobile devices owned or used by individualusers of the IMS, such as individual employees or members of theorganization that operates or utilizes the IMS. For example, the IMS maycollect and manage all employees' data and metadata generated fromsmartphones, tablet computers, laptops and/or other mobile devices(which may be referred to herein simply as “mobile data”). FIG. 7A is aflow chart that illustrates a process 700 for sending mobile data to aninformation management system that may be performed at a mobile device,e.g., by the distribution client module 405. In some examples, beforethe process 700, the distribution client module 405 and accompanyingdata management agents 280 are downloaded and installed on a user'smobile device as a mobile application (e.g., via a company's intranet,via an “app store” or via another distribution channel).

The process 700 begins at block 705, where the distribution clientmodule 405 receives IMS authentication information and managementpolicies for the mobile data from a mobile device. FIG. 7C illustratesone example of a graphical user interface 770 that the distributionclient module may provide on the mobile device in order to receiveauthentication information and management policies. As shown, theinterface 770 may include IMS username and password fields, 772 and 774,so that the user of the mobile device can provide authenticationinformation or credentials that identify the person as a registered userof the information management system 150 (e.g., as IMS user “jane65”).Although not shown, the interface 770 may also include a field to permitthe IMS user to provide an identifier associated with the particular IMSshe is associated with. The interface 770 also includes a device aliasfield 775 whereby a user can provide a descriptive alias for the mobiledevice that permits the user and the IMS to readily identify the mobiledevice as a data source for the user.

The interface 770 includes several selection boxes 776 or similarelements to permit the user to identify what types of mobile data fromthe mobile device the user wants the IMS to collect and manage. Forillustrative purposes, the interface 770 shows only the data types ofpictures, documents, emails, applications and application data. However,as indicated by the selection field 776 e, the information managementsystem may also support the collection and management of numerous othertypes of mobile data. Moreover, in some examples, the interface 770permits a user to define more granular criteria for the mobile data thatshould be collected and managed by the IMS. For example, the interface770 might permit a user to define which particular applications andapplication data are collected and managed and/or might permit the userto define other selection criteria (such as file size, file extension,or particular source directory folders on a mobile device).

The interface 770 also includes policy selection menus 778 or similarselection means so that the user can associate each selected data type(or all data types) with a particular information management policy forcollecting, managing or distributing the selected type of data. Aselected policy may include any of the criteria and rules describedabove in connection with the discussion of information managementpolicies generally. A selected policy may specify the frequency withwhich the distribution client module collects data from the mobiledevice, the type of network connectivity that can or cannot be used fordata collection or distribution (e.g., a WiFi connection or a domesticcellular network), a specific “blacklist” of network access points or IPaddresses that cannot be used for data collection or distribution, aspecific “whitelist” of network access points or IP addresses that maybe used for data collection or distribution, and operating conditionssuch as battery life that must be satisfied during data collection ordistribution. The policy may also specify that certain data objectscannot be opened on the mobile device unless the mobile device is withina certain IP address range or connected via a specific network. Thepolicy may specify particular directories on the mobile device filesystem for which data should be collected and managed. The policyselected may also specify the types of information management operationsthat should be performed on the mobile data after it is collected (e.g.,deduplication, content indexing, data classification, archiving, etc.).The selected policy may also specify where or how non-production copiesof the mobile data should be stored. As shown with element 778 a, tosimplify the user experience, the interface 770 may provide a suggesteddefault or mandatory policy (e.g., a Default policy where data iscollected once a day, and only when the mobile device has a WiFiconnection). To illustrate the use of the interface 770, in the exampleshown in FIG. 7C, the IMS user “jane65” has opted to have the pictures,documents, applications and application data on her mobile device sentto the IMS once a day when there is a WiFi connection available.

Although not shown in FIG. 7C, it should be noted that the informationmanagement system 150 permits administrators of the informationmanagement system to define or modify information management policiesfor the mobile data of other users, including policies that prohibit thecollection and management of certain mobile data. For example, an IMSadministrator may create a system-wide policy that specifies that photosthat originate from any employee's mobile device cannot be collected. Asanother example, an IMS administrator may set a policy that prohibitsemployees from connecting a mobile device to the IMS unless the IMSadministrator has already added an identifier for the mobile device(e.g., an IMSI or IMEI) to a system-wide “whitelist” of authorizeddevices. The IMS may disregard any information management policies setby an individual user to the extent those individual rules are contraryto an administrator-defined policy.

Returning to FIG. 7A, at block 710, the distribution client module 405associates the mobile device with the user. For example, thedistribution client module may send identifying information to thedistribution module 490 such as: the IMS user authentication informationobtained at block 705 (e.g. “jane65” and password or other credentials),the alias given to the mobile device, and/or identifiers for the mobiledevice (e.g., hardware, software, or subscriber identifiers associatedwith the mobile device such as an international mobile equipmentidentity (IMEI), international mobile subscriber identity (IMSI), and/orMAC address). In response, in an IMS user profile data structure, thedistribution module may associate the identified IMS user with thedevice alias and other identifiers. The distribution module 490 may alsoprovide the distribution client module with an indication of aparticular distribution module 490 that will service the mobile deviceduring data collection or distribution.

At block 715, the distribution client module 405 sets or adjustsinformation management policies to govern the collection and managementof the mobile data from the mobile device. For example, in accordancewith the user's policy preferences that were received at block 705, foreach data type selected, the distribution client module may set a policyspecifying the schedule and other rules for sending mobile data to aninformation management system. Continuing the previous example, thedistribution client module may set a policy to collect all of jane65'spictures, documents, applications and application data from the tabletnamed “Janes tablet” once a day when a WiFi connection is available. Thedistribution client module may also send the policies to othercomponents, such as a storage manager 402 or the distribution module490.

Next, at block 720, the distribution client module 405 sends mobile datafrom the mobile device to an IMS in accordance with the applicableinformation management policies. The mobile data may be sentopportunistically, e.g., when a high-speed or low cost networkconnection such as WiFi is available. The distribution client module mayinstruct data management agents installed 280 on the mobile device tosend data both in (1) an initial operation so the IMS can collectexisting data objects from the mobile device and (2) in subsequentscheduled operations so the IMS can collect new or modified data objectsfrom the mobile device. Returning to the previous example, after theuser preferences have been received at block 705, if a WiFi connectionis available, the distribution client module may initially instructvarious installed data management agents 280 to package up and send anyof jane65's existing pictures, documents, applications and applicationdata from the tablet named “Janes tablet” to a distribution module 490.From thereon, once a day, when a WiFi connection is available on theJanes Tablet device, the distribution client module may instruct variousinstalled data management agents 280 to package up and send any changesto jane65's pictures, documents, applications and application data tothe distribution module 490. After block 720 the process 700 ends.

Although the process 700 was described as being performed by adistribution client module 405 on the mobile device whose data is beingsent, some or all of the process 700 may be performed by anothercomputing device that acts as an intermediary. For example, a mobiledevice may tether (physically or wireless) to a laptop or desktopcomputer and a distribution client module on the laptop or desktopcomputer may perform some of the steps in the process 700.

FIG. 7B is a flow chart that illustrates a process 750 for managingmobile device data that may be performed at a distribution module 490.As shown, the process 750 begins at block 755 where the distributionmodule receives mobile data in accordance with applicable informationmanagement policies, e.g., in response to a distribution client module405 or a data management agent 280 sending mobile data at block 720 inprocess 700. At block 760, the distribution module 490 manages thereceived mobile data in accordance with applicable informationmanagement policies, such as the information management policies set atblock 715 in process 700. For example, the distribution module mayperform deduplication, content indexing, data classification, orarchiving of the mobile data; create additional non-production copies ofthe mobile data (e.g. backup copies or archive copies); restore themobile data to a new production location; perform information lifecyclemanagement of the mobile data; or perform other information managementoperations upon the received mobile data. After block 760, the process750 concludes.

Distributing User's Data

In addition to collecting and managing a user's data from hostedservices and/or mobile devices, the information management system 150may also distribute a user's data and/or indices of a user's data sothat the user can obtain a unified view of all of her data, acrossdifferent hosted services and different computing devices and access allof this data readily. For example, the information management system maypermit a user to view all of her mobile data, hosted data, and otherdata in a manner similar to that shown in FIG. 13, which is discussed ingreater detail herein.

Before data is distributed, the distribution module 490 may performvarious management tasks to facilitate subsequent distribution. FIG. 8Ais a flow chart that illustrates a process 800 for managing a user'sdata that may be performed by a distribution module 490. The process 800begins at block 805, where the distribution module receives informationmanagement policies for a user's data, specifically distributionpolicies that specify how a user's data should be distributed todifferent computing devices and/or portals.

FIGS. 9A and 9B show some examples of graphical user interfaces that maybe utilized to receive the distribution policies for a user's data. Asshown in FIG. 9A, a management interface 900 may reflect numerous userpreferences for an information management system (such as backup contentand schedules, data restoration options, and alerting options). Themanagement interface 900 includes a subsidiary distribution policiesinterface 917 that reflects existing distribution policies. Thedistribution policies interface 917 may show the details of existingdistribution policies implemented by the distribution module 490. Forexample, the portion of the distribution policies interface 917 shownindicates the details of two existing distribution policies. As shown at904-910, the user “jane65” has defined a first distribution policycalled “impt data sync,” which entails distributing all of the files ina directory defined by a URL, link or path “/this/is/a/path” from JanesLaptop to Janes Tablet in directory defined by another URL, link or path“/another/path.” Second, as shown at 912-918, the user jane65 has alsodefined a second distribution policy called “Push FB pics,” whichentails sending all Facebook pictures from jane65's hosted accounthaving the alias “Facebook Jane” to all of jane65's associated devices.As shown, jane65 is also provided with access to these pictures from aweb-based portal, as described further herein. Selectable elements 911and 919 such as hyperlinks or menu options, provide a user with theability to edit the settings of existing distribution policies. Aselectable element 920 such as a hyperlink or menu option provides auser with the ability to add a new distribution policy and adjust itssettings.

FIG. 9B illustrates an example of a graphical user interface 930 fordefining a distribution policy. The interface 930 may be displayed, forexample, in response to a user selecting one of the selectable elementsof FIG. 9A, such as 911, 919 or 920 in order to create a newdistribution policy or edit an existing distribution policy. As shown,the interface 930 includes a distribution policy name field 932 anddescription field 934 to permit a user to edit a name and a narrativedescription for the distribution policy. The interface 930 also includesfields 936, 938, 940, other types of menus 942, dynamic lookup fields,or similar to permit a user to build a set of criteria that define whichset of data objects should be distributed under the policy. Although notshown, the interface 930 may include options for creating complexexpressions of criteria, including expressions that utilize Booleanoperators and set operators.

As one example, as shown, the interface 930 may permit a user to specifya source location, a file type, and a modification date in order todefine the set of data objects that should be distributed under thepolicy. A source location may be defined by an alias for a hostedaccount, an alias or hostname for a computing device (including mobiledevices), and/or a directory path within a hosted account or computingdevice. Of course, other types of criteria may be used to define the setof data objects that should be distributed, including, withoutlimitation file size, access control information, data classificationtags, content information (e.g., keywords), and modification or creationdates.

The interface 930 also includes input fields 944, 946, and other typesof menus 948 that permit a user to select one or more destinationlocations to where the defined set of data objects should bedistributed. The destination locations may include specific computingdevices, a class of computing devices (e.g., all computing devicesassociated with a particular user, all computing devices having certaincharacteristics such as having more than a threshold capacity of diskspace or a particular application installed), and/or a directory withina specific computing device or within a class of computing devices. Bypermitting a user to define a destination directory, a user can mergedata from multiple sources into a specific folder on a destinationdevice. In some examples, a user can omit a source directory path anddestination directory path from the criteria, so that all data from asource device (e.g., a smartphone) is synchronized with all of the dataat a destination device (e.g., a tablet).

Although not shown, a distribution policy may also specify whether apreview version or a copy of a version of an implicated data objectshould be automatically pushed by the distribution module to thedestination location, even if it doesn't receive an explicit request forit from a destination computing device. The policy may also specifytriggers for pushing unsolicited previews or copies. For example, adistribution policy may specify that a preview version or copy of animplicated data object should be pushed immediately when the preview orcopy becomes available (or at the first opportunity thereafter) so thatthe destination device has a cached version available.

A synchronization policy field 950 permits a user to select or definewhether and how data should be synchronized across the source anddestination computing devices and may include pre-definedsynchronization policies and/or a menu option to build a customsynchronization policy. One example of a synchronization policy is aone-way synchronization policy (“push only”), where only changes made toa data object at a source location are pushed or propagated to adestination location but changes made at a destination location are notpropagated back to the source location. Another example is full two-waysynchronization, where all changes made to a data object at any location(any source or destination location) are pushed or propagated to allother locations where a copy of the data object is located. Asynchronization policy may further specify how frequently to distributeor receive changes to a data object (or other conditions fordistributing or receiving data changes). A synchronization policy mayalso specify whether to lock access to a data object at locations whereit is distributed if a copy of the object is being edited at anotherlocation. In this way, a synchronization policy may ensure that only onecopy of a data object is unlocked for editing at any given time, so thatonly one computing device can edit the data object. Alternatively, asynchronization policy may specify methods for resolving concurrentediting of the same data object by more than one computing device.Although not shown, the interface 930 may permit a user to define othercharacteristics of a distribution policy, such as conditions precedentfor collecting changes to a data object, receiving changes to a dataobject, opening a data object or preview, or editing a data object.Examples of these conditions include the type of network connectivitythat can or cannot be used for data collection or distribution (e.g., aWiFi connection or a domestic cellular network), a specific “blacklist”of network access points that cannot be used for data collection ordistribution, a specific “whitelist” of network access points that maybe used for data collection or distribution, and operating conditionssuch as battery life that must be satisfied during data collection ordistribution. The policy may also specify that certain data objects orpreview cannot be opened on a computing device unless the computingdevice is within a certain IP address range or connected via a specificnetwork. Other polices are of course possible, including combinations ofthose disclosed herein.

It should be noted that the information management system 150 permits asingle user to define different distribution policies for theirdifferent computing devices, which gives the users more flexibility tocustomize their experience on each device. As just one example, a usermay specify that their photos are synchronized to all their devices buttheir videos are only synchronized across devices that have sufficientdata storage space to accommodate numerous videos. This is in contrastto some conventional techniques for data synchronization, which do notpermit different synchronization policies for different devices.

Also, although not shown in FIGS. 9A and 9B, the information managementsystem 150 permits administrators of the information management system150 to define or modify distribution policies for other users, includingpolicies that prohibit data distribution for certain data objects, tocertain users/locations and/or under certain conditions. For example, anIMS administrator may create a system-wide distribution policy thatspecifies that photos or videos that originate from any employee'sFacebook hosted account cannot be distributed to desktop computers orlaptop computers owned by an organization. The IMS may disregard anydistribution policies set by an individual user to the extent thoseindividual rules are contrary to an administrator-defined policy.

Returning to the discussion of FIG. 8A, after receiving distributionpolicies for a user's data, the distribution module 805 may send thesepolicies to any computing devices implicated by the policy, includingcomputing devices that were identified as a source or destinationlocation. In the example shown in FIG. 9A, the distribution module 805may for example send distribution policies to all of jane65's computingdevices, such as Janes Laptop and Janes Tablet. The distribution modulemay send distribution policies to the distribution client module 405 atthe implicated computing devices to ensure the policies are properlyimplemented. For example, the distribution module may modify aninformation management policy for a source or destination computingdevice so that agents on the device continuously or intermittently pushany changes to implicated data objects to the distribution module 490for subsequent synchronization with the other computing devicesimplicated by the policy.

At block 810, the distribution module 490 receives a user's data objectsand metadata, e.g., by receiving data objects and metadata fromcomputing devices 205 or hosted services 122. The distribution modulemay receive entirely new data objects implicated by a distributionpolicy or new versions of data objects that were already subject to adistribution policy. For example, in accordance with an applicabledistribution policy created and implemented at block 805 (or inaccordance with other information management policies, such as backuppolicies), the distribution module may receive data from a user'scomputing device 205. Alternatively, or additionally, the distributionmodule 490 may receive hosted data that is implicated by a distributionpolicy by pulling the data from a hosted service in accordance withinformation management policies, as described previously at block 520.

At block 810, the distribution module 490 may receive a new version of adata object, e.g., either by receiving a copy of the changed data objectitself or by receiving a copy of any blocks that have changed since thelast version of the data object was received by the distribution module.Additionally, at block 810, instead of receiving a copy of a particulardata object or a constituent block of a data object, the distributionmodule may receive a hash or other substantially unique identifier forthe data object or a constituent block, if source-side deduplicationtechniques are implemented, e.g., as described in assignee's U.S. patentapplication Ser. No. 12/982,087, filed Dec. 30, 2010, entitled Systemsand Methods for Retaining and Using Data Block Signatures in DataProtection Operations (attorney docket no. COMMV.084A, which is herebyincorporated by reference herein in its entirety, and commonly-assignedU.S. patent application Ser. No. 12/751,850, which was introduced andincorporated by reference above. In conjunction with receiving data atblock 810, the distribution module may also receive metadata associatedwith the data object, such as a file name, file or data object type,source directory, access control information, creation time, file orobject size, and modification time.

At block 815, the distribution module 490 analyzes and indexes the dataand metadata received at block 810. For example, for each data objectreceived, the distribution module may perform content indexing and dataclassification analyses of the data object, as described further in theassignee's U.S. Pat. Nos. 7,822,749 and 7,882,077, both of which arehereby incorporated herein by reference. The distribution module maystore the results of the analyses and other information related to thedata object in an object log index 1000, such as that shown in FIG. 10.The object log index may include one row for every version of a dataobject that is subject to a distribution policy. As shown, the objectlog index 1000 may include an object ID column 1002, a version ID column1004, a hash column 1006, a user ID column 1008, an object lookup column1010, a source column 1012, an object name column 1013, an analysis datacolumn 1014, a time stamp column 1016, and a preview column 1020.Together, the object ID column, which stores data object identifiers,and the version ID column, which stores version numbers or similarversion identifiers, provide a unique key for the table (though otherIDs may be used in alternative embodiments). The hash column 1006includes a hash, checksum, digest or other substantially uniqueidentifier of the content of a data object to aid in deduplication andobject identification. The user ID column 1008 identifies a user who isassociated with a data distribution policy that implicates the dataobject. The object lookup column 1010 provides a pointer or otherreference to one or more stored copies of the version of the data objectsuch as production or nonproduction copies of the version of the dataobject. The source column 1012 indicates where the version of the dataobject originated from, such as the hostname (or device alias) anddirectory from which the object originated, or a hosted service aliasand hosted directory that produced the data object. The analysis datacolumn 1014 points to or otherwise provides access to metadata, contentindexing information, and data classification tags associated with theversion of the data object. The timestamp column 1016 indicates when theversion of the data object was received by the distribution module (oralternatively, the modification time of the version, as determined fromits source). The preview column 1020 includes a pointer or otherreference to one or more preview versions of the version of the dataobject. Each preview version may be a simplified or otherwise optimizedversion of the data object suitable for the user interface capabilitiesof a particular computing device or class of computing devices acrosswhich the data object is distributed. For example, a preview of aPowerPoint presentation suitable for a mobile device may be a limitedfunctionality HTML or PDF version of the presentation. More discussionof appropriate methods for generating preview versions of data objectsmay be found in the commonly-assigned and concurrently-filed U.S. patentapplication Ser. No. ______ entitled “Smart Archiving and DataPreviewing for Mobile Devices,” filed Mar. 30, 2012 (Attorney Docket No.606928098US00), which is hereby incorporated by reference herein in itsentirety.

Returning to the process 800 of FIG. 8A, at block 820, the distributionmodule 490 creates additional non-production copies of the received dataobjects and metadata, for example, in accordance with applicableinformation management policies. For example, an information managementpolicy may mandate that each received version of a data object should bestored both as a backup copy in disk media and also in an archive formaton tape for long-term storage. When creating additional non-productioncopies of the received data objects and metadata, the distributionmodule may update the object lookup column 1010 in the object log index1000 to reflect the storage locations of these additional non-productioncopies.

At block 825, the distribution module 490 determines where to distributecopies of the received data objects, index information related to thereceived data objects, and/or preview versions of the received dataobjects. For example, the distribution module may analyze thedistribution policies received at block 805 and any other applicableinformation management policies to determine that it should distribute areceived data object, its related index information, and/or a previewversion of the object to a particular destination location, such as aparticular destination computing device. In some examples, thedistribution module 490 records the result of its determinations in adistribution index 1100, such as that shown in FIG. 11, which includes asingle row for each unique combination of a version of a data object anda destination location. As shown, the distribution index 1100 includes auser ID column 1102, an object ID column 1106, and a version ID column1108, that together identify a row in the object log index 1000. Thedistribution index 1100 also includes a destination column 1104, whichindicates a particular destination device (or web portal) that shouldprovide user access to the version of the data object, index informationfor the object (such as metadata), or a related preview version. Thedistribution index 1100 also includes a destination directory column1105 that indicates where in a destination directory tree structure thedata object should be placed. For example, rows 1101 and 1103 indicatethat Janes Laptop and Janes Tablet should both receive version 1 of thedata object identified by object ID 123456 (i.e., the “Image1.jpg”object described by row 1030 in FIG. 10) and the user will be able tofind the “Image1.jpg” file in the directory folder “FacebookJane/pics/European Album.” Row 1105 indicates that jane65 should also beable to access the Image1.jpg from a web-based portal, as describedfurther herein.

The distribution index 1100 may also include one or more columns totrack whether and when a data object, a related preview, or relatedindex information about a data object has been distributed to aparticular destination. For example, an index sent column 1110 indicateswhen a particular destination device (or portal) receives indexinformation about the version of the data object, as described furtherherein. As another example, a preview sent timestamp column 1112indicates when a particular destination device or portal receives apreview version of a data object. As yet another example, a copy sentcolumn 1114 indicates when a particular destination device or portalreceives a copy of a particular version of the data object. A copylocked column 1116 indicates whether a particular computing device orportal is actively editing an object and thus, under the applicablesynchronization policy, other computing devices or portals should beblocked from simultaneously editing the object.

Of course, different types of index data structures could providesimilar functionalities to those described in connection with the objectlog index 1000 and distribution index 1100. Additionally, in accordancewith applicable storage policies, the distribution module mayintermittently or on a prescribed schedule prune the indices 1000 and1100 to remove all references to versions of data objects that meetpredefined criteria (e.g., older versions that haven't been accessedduring a prescribed period). Additionally, the distribution module maydelete stored non-production copies and/or preview versions of thesepruned data objects.

Returning to FIG. 8A, after the distribution module 490 determines whereto distribute data objects, index information, and/or preview versionsof the received data objects, the process 800 ends.

A distribution client module 405 may perform actions that arecomplementary to the process 800 performed by a distribution module 940.FIG. 8B is a flow chart that illustrates a process 850 for managing auser's data that may be performed at a computing device, e.g., by adistribution client module 405. The process 850 begins at block 855,where the distribution client module 405 receives information managementpolicies for a user's data, including distribution policies. Forexample, as described previously at block 805, the distribution clientmodule 405 may receive user-defined distribution policies from thedistribution module 490. Alternatively, the distribution client module405 may directly receive distribution policies from a user (for example,if the distribution client module provides interfaces similar tointerfaces 900 and 930) and may push these received distributionpolicies to the distribution module 490.

At block 860, the distribution client module 405 detects changes to auser's data objects that are implicated by a distribution policy, i.e.,objects that match the criteria specified by a distribution policy. As afirst example, the distribution module may determine that a user hascreated a new file implicated by a distribution policy. As a secondexample, the distribution module may determine that a user has openedand edited a file on a source device, and the file is implicated by adistribution policy that specifies one-way or two-way synchronizationacross devices. As a third example, the distribution client module maydetermine that a user has opened and edited a file at a source ordestination location, and the file is implicated by a distributionpolicy that specifies two-way synchronization across devices.

At block 865, the distribution client module 405 sends a copy of theimplicated data objects to the distribution module 490 in accordancewith the distribution policies (i.e., resulting in block 810 of process800). The timing of block 865 may be mandated by settings of thedistribution policy and may be opportunistic (e.g., when a low-cost orhigh-speed network connection is available to the distribution clientmodule). For example, the distribution policy may specify particularconditions for sending the data objects such as requiring that thedevice sending the copy is on a corporate network or corporate VPN, hasWiFi or another type of network access, has a minimum level of batterypower left, etc. After block 865, the process 800 ends. The data objectsmay be sent using continuous data replication techniques such thosetechniques described in assignee's U.S. patent application Ser. No.12/167,933, entitled “Continuous Data Protection Over IntermittentConnections, Such as Continuous Data Backup For Laptops or WirelessDevices,” filed Jul. 3, 2008, now U.S. Patent Publication Number2010-0005259 (attorney docket 606928055US00) and/or source-sidededuplication techniques such those techniques described incommonly-assigned U.S. patent application Ser. No. 12/982,087(introduced earlier above) and assignee's U.S. patent application Ser.No. 12/751,850 (introduced and incorporated by reference earlier above),all of which are hereby incorporated by reference herein in theirentirety.

Unified Views of a User's Data

As introduced above, the information management system 150 maydistribute a user's data and/or indices of a user's data so that theuser can obtain a unified view of all of her data that has been createdand modified across different hosted services and different computingdevices. The information management system permits the user to obtainthis unified view and access her data on different computing devices orvia a web portal.

FIG. 13 illustrates one example of a graphical user interface 1300 forproviding a user with unified access to their data, including data thathas originated from multiple computing devices and/or multiple hostedservices. As shown, the interface 1300 may depict a user's data as anavigable directory or folder tree having different branches and dataobjects (represented by icons) within those branches. Each main branchin the directory tree may represent a different hosted service orcomputing device associated with the user via a distribution policy. Forexample, jane65's data is represented as a directory tree structure,where her “Flickr JaneDoe” hosted data falls under the main branchrepresented by the icon 1312, her “Facebook Jane” hosted data fallsunder the main branch represented by the icon 1314, her “Gmail Jane”hosted data falls under the main branch represented by the icon 1316,the data originating from her laptop with alias “Janes Laptop” fallsunder the main branch represented by the icon 1318, and the dataoriginating from her tablet with alias “Janes Tablet” falls under thebranch represented by the icon 1320. Each branch in the tree may havedata objects and/or subsidiary folders. The subsidiary folders used tohouse a particular data object may reflect the directory path of thedata object on a source computing device or hosted service that createdor modified the data object. For example, as shown, “this/is/a/path” isthe directory path on Janes Laptop where the documents Doc1.doc andDoc2.doc originated from. The folder used to house a particular dataobject may be specified by a distribution policy. For example, adistribution policy that implements two-way synchronization may specifythat data objects that originated in a first directory path (e.g.,“this/is/a/path”) on a first source computing device should also bepresented in a second directory path (e.g., “a/different/location”) of asecond destination device. Alternatively, or additionally, thesubsidiary folders used to contain a particular data object may reflectmetadata or other characteristics of the data object. For example, thetwo files “Image1.jpg” and “Image2.jpg” are shown under the “FacebookJane/Pics” branch in accordance with a distribution policy but are alsoshown under the subsidiary “European Album” folder to indicate the nameof a Facebook album from which they originated.

The interface 1300 may also provide the user with multiple ways toaccess their data objects. For example, if a user selects an iconassociated with a data object (e.g., icon 1305), the user may bepresented with a menu 1310 of options, such as the options of

-   -   (1) opening a read-only preview version (e.g., a PDF or HTML        version) of the newest version of the data object using a        limited-feature viewer application (e.g., a pdf viewer or a        browser),    -   (2) opening a full version (e.g., a .doc version) of the newest        version of the data object using a locally-installed,        full-featured application associated with the file type of the        data object (e.g., Microsoft Word),    -   (3) opening the data object for viewing or editing by a        full-featured application that is being run in a “live browse”        mode using the processing capabilities of another, remote        computing device (e.g., Janes Laptop), as described further        herein,    -   (4) opening a preview of an older version of the data object        using a viewer,    -   (5) opening a copy of an older version with a locally-installed,        full-featured application.

Additionally, the menu may include an option to perform a “live browse”of the local files of another computing device (e.g., of the device withalias “Janes Laptop”), as described further herein. For example, if auser doesn't see a file they wanted under the “Janes Laptop” branchbecause it wasn't subject to a distribution policy, they may use the“live browse” option to try and locate it on the other device.Alternatively, or additionally, in some examples when a userdouble-clicks a particular data object icon 1305 (or otherwise indicatesthey wish to “open” the data object), the interface may respond bytaking one of these actions by default. The default action taken may bedictated by the capabilities of the computing device presenting theinterface 1300, such as its installed applications, processing power,and memory. For example, on a mobile device, the default action may beopening a preview version using a limited-feature viewer application.

In addition to providing a navigable directory structure, the interface1300 may provide search menus or fields 1315 to permit the user to entersearch criteria and receive a list of search results (or a filtereddirectory structure) that includes the data objects that match thecriteria. For example, if a user enters criteria into the search field1315, the client distribution module may search received contentindexing information, data classification tags, and/or metadata to findand present matching data objects. In this way, the user may be able tosearch across the content, tags, and metadata of data objects thatoriginated from numerous hosted services and/or numerous computingdevices.

Also, the interface 1300 may provide “drag-and-drop” features. Forexample, the interface may permit a user to indicate that they want toreceive a local copy or preview version of an object, simply by draggingan icon into a local directory folder. As another example, the interfacemay permit a user to indicate that they want to push a copy or previewversion of an object to another computing device (thereby effectivelycreating a new distribution policy), simply by dragging an icon for adata object into the displayed navigable folder structure. In otherwords, the user can use the drag-and-drop feature to create adistribution policy to indicate data from one folder or device is to becopied to another location, without having to determine and enter pathnames or other information.

The interface 1300 shown is intended to be illustrative, not exhaustive.The user may obtain a unified view of their data, such as a view ofinterface 1300, in numerous ways. As one example, a user may provide theuser's IMS authentication credentials (e.g., IMS username and passwordor other IMS authentication information) to a dedicated data navigationapplication, such as a downloaded mobile application that comprises adistribution client module 804. Or the application may obtaincredentials from an operating system or directory or security service,such as an Active Directory service. As another example, a user mayprovide the user's IMS authentication credentials (e.g., IMS usernameand password or other IMS authentication information) to a web portalassociated with the IMS in order to view and access her data through apersonalized web interface similar to interface 1300. As anotherexample, a native application installed on a user's computing device mayprovide a unified view of the her data. Examples of native applicationsthat may be used include Windows Explorer or similar file systemnavigators (including NFS/CIFS clients) provided by an operating systemand email clients such as Outlook (or IMAP clients).

In such examples, a distribution client module 405 may be implemented asa plug-in to the native application so that data objects originatingfrom hosted services or other computing devices are presented to theuser within the native application's interface in a manner similar toother locally-stored files or data objects, such as locally-stored filesand locally-stored emails. For example, if a user has created adistribution policy that implements cross-device synchronization,synchronized data objects might simply appear within Windows Explorer ora similar application at a directory location (e.g., /a/different/path)on the destination device specified by the distribution policy. Asanother example, a user may have a folder on their desktop called“Remote Data,” that provides access to an interface similar to 1300. Asyet another example, Outlook may request and cache indexing information,previews and/or copies of synchronized data so that it can provide aninterface such as that shown in FIG. 13, even when it does not havenetwork connectivity.

FIG. 12 is a flow chart that illustrates a process 1200 for providing anIMS user working at a particular computing device with unified access toall of her hosted data and data from other computing devices, includingsynchronized data. The process may be performed at the computing deviceby an installed distribution client module 405, acting alone, or inconcert with another application (e.g. as a plug-in to a nativeapplication such as Windows Explorer or Microsoft Outlook). Although theprocess 1200 is described as being performed to provide an IMS user withunified access to all of the user's hosted data and data from variouscomputing devices, the process 1200 could also be utilized to permitsome IMS users, such as compliance administrators, to obtain a unifiedview of data that was generated by other IMS users, e.g., in order torespond to discovery requests or for other legal compliance reasons.

Prior to the process 1200, the installed distribution client module mayreceive or obtain IMS credentials or other information identifying theIMS user or users whose data is to be presented as noted herein. Stepsin process 1200 may be performed opportunistically, e.g., when alow-cost or high-speed network connection is available to thedistribution client module on the computing device.

The process 1200 begins at block 1205, where the distribution clientmodule 405 requests and receives index information related to the user'sdata, such as information from the object log index 1000 anddistribution index 1100 that is specific to the user and the device orportal from which the user is accessing the data. Typically the requestis made to and fulfilled by the distribution module 490. To illustrate,the distribution client module may request index information related todata objects that have been slated for distribution to the particularcomputing device and are associated with the user, e.g., as indicated bythe destination column 1104 and the user ID column 1102 of thedistribution log 1100. The distribution client module will typicallyrequest and receive sufficient information to permit the distributionclient module to display an organized graphical depiction of the user'sdata, such as that shown in FIG. 13, and to perform searching of dataobjects' content index information, data classification tags, andmetadata. For example, the distribution client module may request, foreach new version of a data object, a destination directory (e.g., from1105), an object name (1013), an object ID (1002), version ID (1004),and metadata and analysis data (1014) such as file type/extension,access control information, and file size. At block 1205, thedistribution client module 405 may request only new index informationand combine the new information with locally cached index information.

Next, at block 1210, the distribution client module 405 provides anavigable graphical display of the user's index information to the user.For example, the distribution client module 405 may interpret thereceived index information (and/or locally cached index information) inorder to produce a graphical representation similar to interface 1300.Alternatively, the distribution client module 405 may interpret thereceived index information in order to instruct another application(e.g., Windows Explorer or Outlook) regarding how to provide a similargraphical representation.

At block 1215, the distribution client module 405 receives a request toprovide a preview of a selected version of a selected object (e.g., viaa menu 1310 or a double-click). In response, at block 1220, thedistribution client module 405 requests a preview version of theselected data object from the distribution module 490 (e.g., by sendingan object ID and version ID). When the distribution client modulereceives the requested preview version, it presents the preview versionto the user using a limited-feature viewer application, such as a PDFviewer or web browser.

At block 1225, the distribution client module 405 receives a request fora copy of a selected version of a selected object (e.g., via a menu 1310or a double-click). In response, at block 1230, the distribution clientmodule 405 requests a copy of the selected version of the selected dataobject from the distribution module 490 (e.g., by providing anassociated object ID and version ID). Once the copy is received, thedistribution client module launches an application capable of openingthe data object, typically a full-featured application associated withthe file type of the data object. If a user edits a copy of a selecteddata object, the distribution client module may push a copy of theedited version back to its source computing device (via the distributionmodule), so that the source computing device has the latest version ofthe data object.

At block 1235, the distribution client module 405 receives a request fora live browse session. These requests are described in further detailherein with respect to FIGS. 14 and 15. The process 1200 then ends.

Although process 1200 has been described as being performed at aparticular computing device, a similar process 1200 may be performed bya web server associated with the IMS that is configured to provide IMSusers with a web portal to access their data. In such examples, thesteps that were described above as being performed by a distributionclient module may instead be performed by a web server.

A distribution module 490 may perform actions that are complementary tothe process 1200 performed by a distribution client module 490. FIG. 14is a flow chart that illustrates a complementary process 1400 forproviding a user with access to her data that may be performed at adistribution module. The process 1400 begins at block 1405, where thedistribution module 405 provides indexing information related to aparticular user and computing device to the distribution client module490. To illustrate, the distribution module may provide indexinformation related to data objects that have been slated fordistribution to the particular computing device and are associated withthe user, e.g., as indicated by the destination column 1104 and the userID column 1102 of the distribution log 1100. The distribution modulewill typically provide sufficient information to permit the distributionclient module to display an organized graphical depiction of the user'sdata, such as that shown in FIG. 13, and to perform searching of dataobjects' content index information, data classification tags, andmetadata. For example, the distribution module may send, for each newversion of a data object, a destination directory (e.g., from 1105), anobject name (1013), an object ID (1002), version ID (1004), and metadataand analysis data (1014) such as file type/extension, access controlinformation, and file size. At block 1410, the distribution module mayprovide only new index information. The distribution module may useinformation such as that shown in column 1110 to identify only the newversions of objects where the indexing information has not already beensent.

At block 1410, the distribution module 490 receives a request to send apreview version of a data object to a distribution client module 405.The request may indicate an object identifier and/or version identifierassociated with a single desired data object. Alternatively, the requestmay ask for preview versions of numerous data objects that match aprovided set of criteria. For example, the request may ask for any newpreview versions generated in the last 30 days, so that those recentpreviews can be cached by the client distribution module 405. Inresponse to the received request, at block 1415, for each indicatedversion of a data object, the distribution module selects a previewversion by using a received data object identifier and versionidentifier (or the received criteria) to look up an associated previewversion from the preview column 1020 of the object log index 1000. Whenselecting the preview version, the distribution module may determine thecapabilities of the device or portal that will be used to display thepreview to the user. The distribution module may then select a previewversion based on the determined capabilities. For example, thedistribution module may determine the hard disk capacity, memorycapacity, video or sound card specifications, network connection type orbandwidth, processing power, and installed applications of the computingdevice and select a preview version that is best suited to thosecharacteristics. More information about selecting preview versionssuitable for a particular computing device can be found in thecommonly-assigned and concurrently-filed U.S. patent application Ser.No. ______ entitled “Smart Archiving and Data Previewing for MobileDevices,” filed Mar. 30, 2012 (Attorney Docket No. 606928098US00), whichis hereby incorporated by reference herein in its entirety. If there isno existing preview version available from the object log index 1000that is suitable for the capabilities of the computing device, thedistribution module may generate a suitable preview version. Thedistribution module then sends the selected preview version(s) to thedistribution client module, which may be performed using source-sidededuplication techniques.

At block 1420, the distribution module 490 receives a request to send acopy of a selected version of a selected data object to a distributionclient module 405. The request may indicate a data object identifierand/or version identifier associated with the desired data object (ormay specify a set of criteria that identifies one or more versions ofone or more data objects). In response to the received request, at block1425, the distribution module locates a copy of the requested version ofa data object by using a received data object identifier and versionidentifier (or other criteria) to look up an associated stored copy fromthe object lookup column 1010 of the object log index 1000. Thedistribution module then sends the located copy to the distributionclient module, which may be performed using source-side deduplicationtechniques. When an applicable synchronization policy specifies locking,as described previously, before performing block 1420, the distributionmodule may verify that the object has not already been locked and afterperforming block 1420, the distribution module may add a “lock” on thedata object to prevent other computing devices from simultaneouslyediting the data object, e.g., by adding a timestamp to column 1116.

At block 1430, the distribution module 490 receives a request from arequesting distribution client module 405 at a requesting computingdevice to facilitate a “live browse” session between the requestingdistribution client module and a second, target computing device. Thereare two variants of a live browse session. A first variant of a livebrowse session presents a user at the requesting computing device with abrowseable and searchable view of data objects on the target computingdevice, even if those data objects have not yet been pushed to thedistribution module 490. In a second variant, the requestingdistribution client module requests to open a data object in a “livebrowse” mode. The second variant permits the requesting distributionclient module to utilize computing resources of the target computingdevice (e.g., processing power, installed applications, memory, harddisk) in order to view or manipulate files and other data objects.

At block 1435, the distribution module 490 responds to the request for alive browse session. When a request for the first variant of livebrowsing is received (i.e., a request to browse the files of a targetcomputing device), the distribution module may first determine if thetarget computing device is online, i.e., has network connectivity to thedistribution module. If the target computing device is not online, thedistribution module may access backup copies of the data from the targetcomputing device and/or indexing information that were created as partof a backup operation in order to create an index similar to that shownin the object log index 1000, which reflects the data contents andorganization of the target computing device. Otherwise, if the targetcomputing device is online, the distribution module may query adistribution client module 405 at the target computing device and ask itto provide an updated index of all of the file folders and data objectson the target computing device (or a subset of its folders and dataobjects). For example, the distribution module may request indexinginformation for each data object similar to the indexing informationshown in the object log index 1000. The distribution module thenprovides the indexing information obtained from either the backupoperations or from the target computer itself to the requestingdistribution client module. The requesting distribution client moduleuses the indexing information to produce an interface with a graphical,navigable and searchable file folder structure of the folders and dataobjects on the target computing device, such as the interface shown inFIG. 13. From the interface, a user may select a displayed object anddrag it to a local directory (e.g., her desktop) so that a copy iscreated locally on the requesting computing device.

The requests and responses at block 1435 may be iterative, so that thedistribution module first obtains and provides only coarse indexinginformation (e.g., only the data objects and folders that appear intop-level file folders of the target device) and then later obtains andprovides additional indexing information, e.g., in response to a usernavigating to a specific folder in a displayed navigable file folderstructure. For example, the distribution module may, upon such usernavigation, obtain and provide more granular indexing information forspecific folders on the target computing device. If a user indicatesthat she wishes to open a preview version or copy of the data objectshown in the navigable folder structure (e.g., as described previouslywith respect to FIG. 13), the distribution module may obtain a previewversion or copy from the target computer (and if necessary, generate asuitable preview version) and provide the preview version or copy to therequesting distribution client module. If a user edits a copy of aselected data object on the requesting computing device, the requestingdistribution client module may push the edited version back to thetarget computing device (via the distribution module), so that thetarget computing device has the latest version of the data object.

In addition to providing index information related to the data objectsavailable on a target computing device, the distribution module may alsodetermine and provide information regarding the applications that areinstalled on the target computing device are capable of being run in a“live browse” mode. In this way, the user can initiate applications onthe target computing device from a requesting device such as alimited-feature mobile device.

The previous discussion described the distribution module as playing anintermediary role by collecting and distributing indexing information,preview versions, and copies of data objects. However, in some examples,instead the target distribution client module may communicate directlywith the requesting distribution client module to exchange thisinformation directly. Also, the requesting distribution client modulemay generate preview versions, as needed.

When a request for the second variant of live browsing is received, inresponse, at block 1435, the distribution module 490 identifies thetarget computing device and establishes a secure connection between arequesting distribution client module and a target distribution clientmodule at the target computing device. Once the connection isestablished, the target distribution client module may initiateapplications installed at the target computing device and provide anoptimized view of the application to the requesting distribution clientmodule. This second feature of a live browse session is described ingreater detail herein, e.g., with respect to FIGS. 15A and 15B. Afterblock 1435, the process 1400 ends.

The distribution module 490 and client distribution module 405 mayperform variants of the processes 1400 and 1200 respectively. As oneexample, instead of providing a preview of a data object only inresponse to an explicit request for the preview, the distribution module490 may instead provide a preview of a data object when a new version ofthe data object is received and indexed, in conjunction with indexinginformation at block 1405, and/or upon a prescribed schedule. As anotherexample, instead of providing a copy of a data object in response to anexplicit request for the copy, the distribution module may insteadprovide a copy of the data object when a new version of the data objectis received and indexed and/or upon a prescribed schedule. In thesevariants, the methods may keep data objects that are being edited atdifferent computing devices synchronized across those differentcomputing devices. When all of the synchronized computing devices havenetwork access, cross-device synchronization may occur nearly inreal-time. In another variant, instead of providing a preview of a dataobject or a copy of a data object only in response to an explicitrequest for a preview or copy, the distribution module may proactivelypush a subset of the previews and data objects (e.g., in conjunctionwith indexing information) and the distribution client module may cachethese so it can respond to user requests even when it has no networkconnectivity. For example, the distribution module may proactively pushpreviews or copies of any objects that have been edited in the last 30days.

Live Browsing

The second variant of a live browse session permits a user of a mobiledevice or other limited-feature device to execute full-featuredapplications installed on a remote computing device (e.g., a desktop orlaptop device) and to interact with the full-featured application viathe input-output hardware of the limited-feature device. As describedabove, when a user of a requesting computing device indicates that theywant to open a data object in a “live browse” mode, a connection isestablished between a distribution client module 405 at the requestingcomputer (the “requesting distribution client module”) and adistribution client module 405 at the target computing device (the“target distribution client module.” The target distribution clientmodule identifies a copy of the data object and if necessary, requests acopy of the data object, e.g., from a distribution module 490. Thetarget distribution client module launches an instance of afull-featured native application using the processor and memory of thetarget computing device in order to open the data object in the nativeapplication.

As shown in FIG. 15A, when a full-featured native application (e.g.,Microsoft Word) is used to edit a file or data object, such as a Worddocument, the computing device where the native application is installedwould normally produce a native graphical interface 1500. The nativeinterface 1500 includes full-featured menus 1525 that permit the user toinitiate numerous and complex menu commands. In contrast, in live browsemode, when a target distribution client module launches a full-featurednative application, the target distribution client module interprets theoutput from the full-featured application in order to produce asimplified graphical interface 1550 for the application, as shown inFIG. 15B. For example, the target distribution client module maygenerate an HTML interface that provides only a highly limited set ofmenu options 1575. The target distribution client module then sends arepresentation of the simplified graphical interface 1575 to therequesting distribution client module, which displays the interface tothe user at the requesting computing device (e.g., in a browser). Thesetwo steps may be repeated as the target distribution client modulereceives updated output from the full-featured application. In concertwith these actions, the target distribution client module may send anyuser input it receives from the simplified graphical interface 1575 backto the target distribution client module. The target distribution clientmodule interprets or translates any received user input and conveys theinput to the native full-featured application. In this way, a user maybe able to utilize, in a limited way, full-featured applications thatare installed at a remote computing device.

Other Features

In some examples, the functionality of the information management systemmay be provided to an organization on a subscription, orsoftware-as-a-service or platform-as-a-service basis. In such examples,the operator of the information management system may charge anorganization on a per-user basis and/or on the basis of other metrics ofusage.

CONCLUSION

Systems and modules described herein may comprise software, firmware,hardware, or any combination(s) of software, firmware, or hardwaresuitable for the purposes described herein. Software and other modulesmay reside on servers, workstations, personal computers, computerizedtablets, PDAs, and other computing devices suitable for the purposesdescribed herein. Modules described herein may be executed by ageneral-purpose computer, e.g., a server computer, wireless device, orpersonal computer. Those skilled in the relevant art will appreciatethat aspects of the invention can be practiced with othercommunications, data processing, or computer system configurations,including: Internet appliances, hand-held devices (including personaldigital assistants (PDAs)), wearable computers, all manner of cellularor mobile phones, multi-processor systems, microprocessor-based orprogrammable consumer electronics, set-top boxes, network PCs,mini-computers, mainframe computers, and the like. Furthermore, aspectsof the invention can be embodied in a special purpose computer or dataprocessor that is specifically programmed, configured, or constructed toperform one or more of the computer-executable instructions explained indetail herein.

Software and other modules may be accessible via local memory, anetwork, a browser, or other application in an ASP context, or viaanother means suitable for the purposes described herein. Examples ofthe technology can also be practiced in distributed computingenvironments where tasks or modules are performed by remote processingdevices, which are linked through a communications network, such as aLocal Area Network (LAN), Wide Area Network (WAN), or the Internet. In adistributed computing environment, program modules may be located inboth local and remote memory storage devices. Data structures describedherein may comprise computer files, variables, programming arrays,programming structures, or any electronic information storage schemes ormethods, or any combinations thereof, suitable for the purposesdescribed herein. User interface elements described herein may compriseelements from graphical user interfaces, command line interfaces, andother interfaces suitable for the purposes described herein.

Examples of the technology may be stored or distributed oncomputer-readable media, including magnetically or optically readablecomputer disks, hard-wired or preprogrammed chips (e.g., EEPROMsemiconductor chips), nanotechnology memory, or other data storagemedia. Indeed, computer-implemented instructions, data structures,screen displays, and other data under aspects of the invention may bedistributed over the Internet or over other networks (including wirelessnetworks), or they may be provided on any analog or digital network(packet switched, circuit switched, or other scheme).

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense, as opposed to anexclusive or exhaustive sense; that is to say, in the sense of“including, but not limited to.” As used herein, the terms “connected,”“coupled,” or any variant thereof, means any connection or coupling,either direct or indirect, between two or more elements; the coupling orconnection between the elements can be physical, logical, or acombination thereof. Additionally, the words “herein,” “above,” “below,”and words of similar import, when used in this application, refer tothis application as a whole and not to any particular portions of thisapplication. Where the context permits, words in the above DetailedDescription using the singular or plural number may also include theplural or singular number respectively. The word “or,” in reference to alist of two or more items, covers all of the following interpretationsof the word: any of the items in the list, all of the items in the list,and any combination of the items in the list.

The above Detailed Description is not intended to be exhaustive or tolimit the invention to the precise form disclosed above. While specificexamples for the invention are described above for illustrativepurposes, various equivalent modifications are possible within the scopeof the invention, as those skilled in the relevant art will recognize.For example, while processes or blocks are presented in a given order,alternative implementations may perform routines having steps, or employsystems having blocks, in a different order, and some processes orblocks may be deleted, moved, added, subdivided, combined, and/ormodified to provide alternative or subcombinations. Each of theseprocesses or blocks may be implemented in a variety of different ways.Also, while processes or blocks are at times shown as being performed inseries, these processes or blocks may instead be performed orimplemented in parallel, or may be performed at different times. Furtherany specific numbers noted herein are only examples: alternativeimplementations may employ differing values or ranges.

The teachings of the invention provided herein can be applied to othersystems, not necessarily the systems described herein. The elements andacts of the various examples described above can be combined to providefurther implementations of the invention.

Any patents and applications and other references noted above, includingany that may be listed in accompanying filing papers, are incorporatedherein by reference. Aspects of the invention can be modified, ifnecessary, to employ the systems, functions, and concepts of the variousreferences described above to provide yet further implementations of theinvention.

These and other changes can be made to the invention in light of theabove Detailed Description. While the above description describescertain examples of the invention, no matter how detailed the aboveappears in text, the invention can be practiced in many ways. Details ofthe system may vary considerably in its specific implementation, whilestill being encompassed by the invention disclosed herein. As notedabove, particular terminology used when describing certain features oraspects of the invention should not be taken to imply that theterminology is being redefined herein to be restricted to any specificcharacteristics, features, or aspects of the invention with which thatterminology is associated. In general, the terms used in the followingclaims should not be construed to limit the invention to the specificexamples disclosed in the specification, unless the above DetailedDescription section explicitly defines such terms. Accordingly, theactual scope of the invention encompasses not only the disclosedexamples, but also all equivalent ways of practicing or implementing theinvention under the claims.

While certain examples are presented below in certain forms, theapplicant contemplates the various aspects of the invention in anynumber of claim forms. Accordingly, the applicant reserves the right toadd additional claims after filing the application to pursue suchadditional claim forms for other aspects of the invention.

I/We claim:
 1. A method for providing information management of mobiledevice data, comprising: providing a user interface on a mobile devicethat is associated with a user, wherein the mobile device is a cellulartelephone, a smart phone, or a tablet computing device; associating themobile device with an information management system based on selectionsreceived via the user interface, wherein the information managementsystem includes a computing device having a primary storage, wherein thecomputing device executes one or more information management policies togenerate and store non-production copies of information stored by othercomputing devices that are associated with the information managementsystem, wherein the computing device stores the non-production copies insecondary storage devices that are communicatively coupled via a privatenetwork to the computing device; receiving information at the mobiledevice, based on the selections received via the user interface, fordetermining an information management policy to be associated with themobile device; transmitting to the computing device the information fordetermining the information management policy for the mobile device toassociate the information management policy for the mobile device; andtransmitting data and metadata from the mobile device to the informationmanagement system in accordance with the information management policyfor the mobile device.
 2. The method of claim 1, wherein associatingincludes: identifying the information management system based on theselections received via the user interface; receiving a user name and apassword via the user interface for access to the information managementsystem; and establishing a trusted connection between the mobile deviceand the information management system based on the user name and thepassword.
 3. The method of claim 1, wherein the receiving informationfor determining an information management policy includes: definingwhich file type to transmit to the information management system; anddefining a frequency with which to transmit the data and metadata to theinformation management system.
 4. The method of claim 1, wherein thereceiving information for determining an information management policyincludes: defining which of multiple secondary storage devices and othercomputing devices of the information management system are allowed toreceive the data and metadata.
 5. The method of claim 1, wherein thereceiving information for determining an information management policyincludes determining multiple information management policies for themobile device, wherein each information management policy is associatedwith a particular application or data file type, wherein eachinformation management policy independently defines a frequency fortransmitting its associated data and metadata.
 6. The method of claim 1,wherein the receiving information for determining an informationmanagement policy includes: defining which a type of mobile devicenetwork connectivity that the mobile device is permitted to use in orderto perform the transmitting the data and the metadata; and definingoperating conditions of the mobile device that must be satisfied beforethe mobile device is permitted to perform the transmitting the data andthe metadata, wherein the operating conditions include an amount ofbatter life remaining for the mobile device.
 7. The method of claim 1,further comprising: receiving, by the mobile device, data objects fromthe information management system that are distributed to multiplecomputing devices associated with the information management system; andreceiving an administrator information management policy for the mobiledevice from the information management system, wherein the administratorinformation management policy determines which of the data objects, fromthe information management system, the mobile device is permitted toopen while the mobile device is not connected to a private networkassociated with the information management system.
 8. The method ofclaim 1, wherein the user is an employee of an organization, and whereinthe information management system is a private system for managing dataof the organization.
 9. The method of claim 1, further comprising:installing, by the mobile device, a mobile application that includes adistribution client; and executing the distribution client at the mobiledevice to perform the providing the user interface, the associating themobile device, the receiving information for determining an informationmanagement policy the information policy, the transmitting theinformation management policy, and the transmitting data and metadata.10. At least one non-transitory computer-readable medium carryinginstructions for providing information management of mobile device data,comprising: providing, with a mobile device, a user interface to permita user of an information management system to define informationmanagement policies for the mobile device, wherein the mobile deviceincludes wireless communication capabilities, and, wherein the user isone of multiple users associated with an organization; receivingdefinitions of the information management policies for the mobile devicefrom the provided interface; sending information identifying the userand the mobile device to the information management system; sending theinformation management policies defined from the interface to theinformation management system; and sending data from the mobile deviceto the information management system in accordance with the definedinformation management policies and other applicable informationmanagement policies.
 11. The at least one non-transitorycomputer-readable medium of claim 10 wherein the user interface isprovided by a mobile application installed on the mobile device.
 12. Theat least one non-transitory computer-readable medium of claim 10 whereinthe defined policies mandate sending specified types of data from themobile device to the information management system.
 13. The at least onenon-transitory computer-readable medium of claim 10 wherein the definedpolicies mandate sending data only from selected directories on themobile device to the information management system.
 14. The at least onenon-transitory computer-readable medium of claim 10 wherein the otherapplicable information management policies include a data distributionpolicy for distributing the data from the mobile device to othercomputing devices associated with the information management system. 15.The at least one non-transitory computer-readable medium of claim 10wherein the defined information management policies specify that data issent from the mobile device to the information management system over aparticular type of network connection, wherein particular types ofnetwork connections include WiFi connections, cellular connections,Bluetooth connections, and universal serial bus connections.
 16. Asystem for managing mobile device data, comprising: at least oneprocessor; means for associating a mobile device with a user of aninformation management system; means for associating the mobile devicewith information management policies that have been defined via a userinterface rendered by the mobile device and that are associated with theinformation management system; and means for providing data from themobile device to the information management system to enable theinformation management system to perform information managementoperations upon the data from the mobile device within the informationmanagement system in accordance with the information managementpolicies.
 17. The system of claim 16, further comprising: means fordefining which secondary storage devices and other computing devicesassociated with the information management system are allowed to receivethe data from the mobile device.
 18. The system of claim 16, furthercomprising: means for generating previews of a portion of content of thedata from the mobile device; and means for providing the previews to theinformation management system along with the respective data from whichthe previews are generated.
 19. The system of claim 16, furthercomprising: means for receiving, by the mobile device, data objects fromthe information management system that are distributed to multiplecomputing devices associated with the information management system; andmeans for receiving an administrator information management policy forthe mobile device from the information management system, wherein theadministrator information management policy determines which of the dataobjects, from the information management system, the mobile device ispermitted to open while the mobile device is not connected to a privatenetwork associated with the information management system.
 20. Thesystem of claim 16, further comprising: means for installing, by themobile device, a mobile application that includes a distribution clientfor selectively distributing data from the mobile application to othercomputing devices associated with the information management system.